1. Technical Field
The present invention relates in general to device drivers and software emulation of hardware devices, and, in particular, to a method and data processing system for testing a device driver entirely in software. Still more particularly, the present invention relates to a method and system for testing a device driver that invoke an exception handler to map a target address range to a data space range of the operating system and to emulate a target hardware device if the target address range is outside of the data space range.
2. Description of the Related Art
With reference now to the figures and in particular with reference to FIG. 1, there is illustrated a software layer diagram 100 that shows a device driver 108 in relationship to an application program 102, operating system 104, and firmware 106 of a data processing system. Firmware 106 is generally the layer interposed between hardware, such as target device 110, and operating system 104 and interacts with the hardware to perform designated tasks. Application program 102, in contrast, runs on top of operating system 104 and frequently uses abstract constructs to perform its operations. Application program 102 often relies upon firmware 106 to accomplish the pragmatic task of controlling the data processing system hardware. When application program 102 is executed, application program 102 calls on firmware 106. Firmware 106, in turn, maps commands of application program 102 to the respective hardware.
FIG. 1 shows that device driver 108 is typically part of firmware 106. Device drivers 108 are well known in the art. The development of device driver 108 is straightforward if target device 110 actually exists during or before the time device driver 108 is being developed. Device driver 108 is tested by installing device driver 108 into a data processing system, coupling target device 110 to a data processing system, and running application program 102 under an operating system 104 that requests access to and operation of target device 110. If access to and operation of target device 110 is successful, then device driver 108 has been successfully tested. However, if target device 110 does not exist during or before development of device driver 108, testing of device driver 108 requires simulation of hardware target device 110.
Since a device driver is generally a routine used by an application program 102 to drive hardware target device 110, a conventional device driver usually involves mapping between two sets of commands, a software command set for application program 102 and a hardware command set for target device 110. The software command set generally includes commands for the software, such as Aload@ and Astore@ commands. The hardware command set generally comprises commands for the hardware, such as Ainport@ and Aoutport@ commands. Also, software commands generally translate over to respective hardware commands. For example, the Aload@ and Astore@ commands for a software program respectively correlate to the Ainport@ and Aoutport@ commands for a hardware device. A memory mapped input/output (IO) architecture has been developed to simplify the command set for a device driver (i.e., simplify the two command sets into one command set). The trend has been to simplify and use memory mapped IO device drivers rather than the conventional device drivers that directly interact with hardware devices.
Memory mapped 10 generally involves allocating an address range to one or more IO devices in a data processing system. The address range maps accesses to physical hardware addresses to the allocated address range so that hardware commands are treated as software commands, which are usable by a software or firmware program, such as a device driver. Through use of the memory mapped IO, a software or firmware program, such as a device driver, is able to communicate with the hardware device as though the program were communicating directly with memory.
The use of a software emulator for emulating a target device 110 is known in the prior art. U.S. Pat. No. 5,796,984 to Pearce et al. (APearce@) discloses an example of a software emulator of a peripheral hardware device. The software emulator may be used for testing a device driver based on various reasons, such as hardware costs, hardware availability, etc. A conventional way of testing a device driver with a software emulator typically involves using an input/output (IO) interrupt handler. The IO interrupt handler involves taking an exception when an access by the device driver is made to the physical hardware device 110 (i.e., a hardware command is executed by the device driver). Control and access by the device driver is, in effect, re-directed to the software emulator, and the software emulator emulates the behavior of the hardware device 110. Pearce provides an example of using an IO interrupt handler for testing a device driver. Since memory mapped IO device drivers do not attempt direct access and control of hardware device 110 (i.e., do not execute hardware commands), then use of an IO interrupt handler to test a memory mapped device driver would not work.
Without the use of an interrupt or exception handler, re-directing of the accesses by a memory mapped device driver (i.e., re-directing software commands, such as load and store commands) cannot be accomplished. When the memory mapped 10 device driver performs such accesses (i.e., executes software commands), the memory mapped IO device driver, having not been re-directed, may seek to access memory addresses outside the data address space defined by operating system 104 with which the device driver is being executed. Attempts to read from or write to these memory addresses could have potentially disastrous consequences and would therefore be prohibited by operating system 104. Thus, the memory addresses will have a completely different context when device driver 108 is executed with the operating system 104. One possible solution to this problem is to manually modify the code to change all of the addresses so that the addresses are mapped to addresses within the data address space of operating system 104. However, the modification of code and all addresses within the code would be an extremely tedious and time-consuming process and would require the changing of a significantly large number of lines of code. Therefore, testing of a memory mapped IO device driver is presently impossible or very impractical.